This should make it substantially less annoying, and hopefully more
people will find it useful. In particular, it will no longer run tidy
each time you run `git commit --amend` or rebase a branch.

This also warns if you have the old script in pre-commit; see the HACK
comment for details.

Performing UTF-8 decode outside the JSON module makes more sense in almost all cases.

It previously pointed to rust-lang#57563, the conglomerate issue for
`const fn` (presumably under the feature gate `const_fn`).
`const_fn_trait_bounds` weren't mentioned here, so this commit changes
its tracking issue to a new one.

Signed-off-by: Inteon <42113979+inteon@users.noreply.github.com>

This should cover a mostly cross-platform subset of supported exit codes.

…strap.py

I missed this in rust-lang#89757; it made
`x.py test src/bootstrap` very slow.

Previously, rustbuild would give strange errors if you tried to reuse the same build directory under two names:

```
$ mkdir tmp && cd tmp
$ ../x.py check
Building rustbuild
    Finished dev [unoptimized] target(s) in 35.27s
Checking stage0 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
^C
$ cd ..
$ mv tmp/build build
$ ./x.py check
Building rustbuild
   Compiling bootstrap v0.0.0 (/home/jnelson/rust-lang/rust/src/bootstrap)
    Finished dev [unoptimized] target(s) in 11.18s

failed to execute command: "/home/jnelson/rust-lang/rust/tmp/build/x86_64-unknown-linux-gnu/stage0/bin/rustc" "--target" "x86_64-unknown-linux-gnu" "--print" "target-libdir"
error: No such file or directory (os error 2)
```

This fixes the error. Reusing the same build directory is useful if you want to test path-things in
bootstrap itself, without having to recompile it each time.

For good measure, this also reruns the build script when PATH changes.

Make the pre-commit script pre-push instead

This should make it substantially less annoying, and hopefully more
people will find it useful. In particular, it will no longer run tidy
each time you run `git commit --amend` or rebase a branch.

This also warns if you have the old script in pre-commit; see the HACK
comment for details.

r? ``@Mark-Simulacrum`` cc ``@caass``

… r=camelid

Suggest 1-tuple parentheses on exprs without existing parens

A follow-on from rust-lang#86116, split out from rust-lang#90677.

This alters the suggestion to add a trailing comma to create a 1-tuple - previously we would only apply this if the relevant expression was parenthesised. We now make the suggestion regardless of parentheses, which reduces the fragility of the check (w.r.t formatting).

e.g.
```rust
let a: Option<(i32,)> = Some(3);
```

gets the below suggestion:

```rust
let a: Option<(i32,)> = Some((3,));
//                           ^ ^^
```

This change also improves the suggestion in other ways, such as by only making the suggestion if the types would match after the suggestion is applied and making the suggestion a multipart suggestion.

Cleanup c_str.rs

Some code cleanups in `c_str.rs`.
No functional changes.

ref: bytecodealliance/rustix#163

Add From<u8> for ExitCode

This should cover a mostly cross-platform subset of supported exit codes.

We decided to stick with `u8` initially since its the common subset between all platforms that we support (excluding wasm which I think only works with `true` or `false`). Posix is supposed to take i32s, but in practice many unix platforms mask out all but the low 8 bits or in some cases the 8-15th bits. Windows takes a u32 instead of an i32. Bourne-compatible shells also report signals as exitcode 128 + `signal_no`, so there's some ambiguity there when returning exit codes > 127, but it is possible to disambiguate them on the other side so we decided against restricting the possible codes further than to `u8`.

## Related

- Detailed analysis of exit code support on various platforms: https://internals.rust-lang.org/t/mini-pre-rfc-redesigning-process-exitstatus/5426
- rust-lang#48711
- rust-lang#43301
- https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Termination.2FExit.20Status.20Stabilization

…etup, r=Mark-Simulacrum

Fix linking stage1 toolchain in `./x.py setup`

Closes [92319](rust-lang#92319)

Fix linking stage1 toolchain in `./x.py setup`. I guess this can be considered a follow up to rust-lang#89212 by ```@Sl1mb0.```

We create 2 directories and 1 file that are required by rustup to [link a custom toolchain from path](https://github.com/rust-lang/rustup/blob/5225e87a5d974ab5f1626bcb2a7b43f76ab883f0/src/toolchain.rs#L479-L497).

cc ```@jyn514``` and ```@Mark-Simulacrum``` as they were active in rust-lang#89206

…=bjorn3

Drop json::from_reader

Just a small cleanup -- this was essentially unused; the one use site is better suited to reading from &str regardless.

…s-const_fn_trait_bound, r=oli-obk

Update tracking issue for `const_fn_trait_bound`

It previously pointed to rust-lang#57563, the conglomerate issue for `const fn` (presumably under the feature gate `const_fn`). This tracking issue doesn't mention anything about `const_fn_trait_bound`(the only occurrence of "trait bound" is for the now-removed `?const Trait` syntax), which can be confusing to people who want to find out more about trait bounds on `const fn`s. This pull request changes the tracking issue to one meant specifically for `const_fn_trait_bound`, rust-lang#93706, which can help collect information on this feature's stabilization and point users towards `const_trait_impl` if they're looking for const-in-const-contexts trait bounds.

Fixes rust-lang#93679.

```@rustbot``` modify labels +A-const-fn +F-const_trait_impl

…rk-Simulacrum

Use shallow clones for submodules managed by rustbuild, not just bootstrap.py

I missed this in rust-lang#89757; it made
`x.py test src/bootstrap` very slow.

…ulacrum

Rerun bootstrap's build script when RUSTC changes

Previously, rustbuild would give strange errors if you tried to reuse the same build directory under two names:

```
$ mkdir tmp && cd tmp
$ ../x.py check
Building rustbuild
    Finished dev [unoptimized] target(s) in 35.27s
Checking stage0 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
^C
$ cd ..
$ mv tmp/build build
$ ./x.py check
Building rustbuild
   Compiling bootstrap v0.0.0 (/home/jnelson/rust-lang/rust/src/bootstrap)
    Finished dev [unoptimized] target(s) in 11.18s

failed to execute command: "/home/jnelson/rust-lang/rust/tmp/build/x86_64-unknown-linux-gnu/stage0/bin/rustc" "--target" "x86_64-unknown-linux-gnu" "--print" "target-libdir"
error: No such file or directory (os error 2)
```

This fixes the error. Reusing the same build directory is useful if you want to test path-related things in
bootstrap itself, without having to recompile it each time.

For good measure, this also reruns the build script when PATH changes.